第7章 主要プラクティス
全員同席（Sit Together）
チーム全体が入れる大きな部屋で開発をおこなうこと
個人作業をできるようにプライバシーを確保した個室を準備すること
全員同席して実際にコミュニケーションをすることで、チームの生産性が向上する
チーム全体（Whole Team）
プロジェクトの成功に必要なスキルを持ったメンバーをチームの一員にする
プロジェクトの健全にするためには、以下のチーム間が必要になる
帰属意識がある
一緒の仲間と捉える
お互いに仕事、成長、学習を支え合っている
チームの課題に対して、解決スキルを持ち合わせた人がいるならアサインして、解決できればアサインを外せばいい
チームを管理できるメンバーには閾値がある。閾値を超えると信頼関係の構築が難しくなる。
12名までは1日で無理なくやり取りできる人数
150名を超えると顔をおぼえることができない。複数チームで構成できるように、問題を分割して構成する
1人のメンバーが複数の顧客の開発をすると効率がわるいし、チーム感が薄れる。特定の顧客の加わるようにしよう。
情報満載のワークスペース（Informative WorkSpace）
仕事の内容がわかるワークスペースを作ること。メンバーがワークスペースを見た時に15秒で状況を理解できるようにしておく
さらに詳しく見たときには、仕事の問題や潜在的な課題をわかるようにしておく
ストーリーカードを作って壁に貼り付け、Done, 今週, 今回のリリース, これから見積もる, 将来などにグルーピングして管理しておく
机などを向かえ合うことで情報交換することもできる
現在の進捗やとどこっている課題をなどを分析するためのチャートも準備するとい
いきいきとした仕事（Energized Work）
生産的な仕事できる状態で仕事をすること。
長時間労働をすれば解決するという思考のままでは、プロジェクトのバリューが低下する
病気の時には急速に専念すること。そのような状態では役に立たない。
効率的な働き方をしたい場合は、労働時間の改善（インクリメンタル的な）ができる。働く時間を変えずに、時間の使い方を改善していく
たとえば、1日に通知を切って2時間コーディングに徹すると宣言をする。これだけでも十分な改善につながる
ペアプログラミング（Pair Programming）
同じPCを目の前に置いて本番コードを開発していく
具体的にいかのことを行う
お互いにタスクを集中する
システムの改良について意見を出し合う
アイデアを明確にする
パートナーがハマったら主導権を握り、相手の失望感を軽減させる
お互いにチームのプラクティスの説明責任を果たせるようにする
1人で考える時間や作業する時間があれば時間を与え、完了すればペアで確認作業を行う。ペアをリスペクトすることもできる。
ペアプログラミングは実際にやると疲れる。なので、休憩をこまめに挟む。
ペアのパートナーはこまめに変えること。プロジェクトによってはタイマー60分ごとで変えたり、機能単位で交代することもある。
ペアプログラミングをする時には、パーソナスペースを強く意識すること。相手に不快感を与えることにつながる。具体的に以下のことに気を付ける
体の物理的な距離は人によるため、常に意識する
病気の時には控える
異性としてみない。開発メンバーの一員として接する。
ペアを組みたくない時には、マネージャーや上司に相談すること
ペアプログラミングを行う時には、お互いにリスペクスとすることを忘れない
ストーリー（Stories）
ストーリとは顧客に見える機能の単位のこと
ストーリーが決まれば早急に見積もる。そうすれば、ビジネス側の情報を共有できて優先度の管理ができ、価値の高いものから着手することができる。
ソフトウェア開発における要件の20%でビジネスの課題を解決できる。残りの80%は対応しなくていい課題になる
ストーリーには短い名前・絵・簡易的な記述を記載して管理する。メンバーからみやすい場所で管理をする。
Ex: 圧縮を選択して保存する：8時間
現在の圧縮オプションは保存ダイアログの次のダイアログにある
圧縮オプションを保存ダイアログに中に入れたい
週次サイクル（Weekly Cycle）
週の初めのミーティングで、1週間分の仕事の計画を行うこと。
ミーティングでは以下のこと決める
1. 先週の進捗を状況を確認する
2. 今週実装する1週間分のストーリーを顧客に選んでもらう
3. ストーリーをタスクに分解する。タスクを見積もってチームメンバにサインアップする。
ここでいう見積もりとはタスクレベルの見積もりで、ビジネス側に共有するストーリーレベルの見積もりはとは別
今週対応するストーリーが決まったら先に自動テストを先にかいて、開発をすすめる。自動テストが通るまでストーリーの開発をすすめる
基本は週次サイクルは1週間を想定している
計画づくりは基本的に時間の無駄。可能な限り計画づくりのかける時間をへらす工夫が必要
タスクができればメンバーは一番の上のタスクから順番にサインアップしていく。
四半期サイクル（Quarterly Cycle）
四半期分の計画をまとめてたてて、振り返ること。
四半期の計画は以下のことを行う
ボトルネックを特定する
ふりかえりによって有害だが気づいていないボトルネックを特定することができる
修正作業に着手する
四半期のテーマを計画する
テーマに取り組むための四半期分のストーリーを選択する
ここでいうテーマは規模の大きい計画として利用する
プロジェクトを組織に適合させる全体像をに集中する
ゆとり（Slack）
持続可能なペースを確保して精神的に安全な状態で開発をすすめること
ゆとり率を20%導入したバッファを設ける。週40時間働く場合は、32時間実際にストーリーに集中する時間を設けるようにする
10分ビルド（Ten-Minute Build）
自動的なシステム全体をビルドして、すべてのテストを10分以内に実行させること
10分以上経過すると使用頻度がへり、フィードバックの機会を失ってしまう
10分を超えた場合は以下を検討して最適化する
自動化されているか
システムの変更した箇所だけをビルド対象にしているか
変更作業によってリスクが高くなった箇所のみをテストしているか
継続的インテグレーション（Continuous Integration）
数時間以内に変更箇所のインテグレーションとテストをすること
継続的インテグレーションは一般的には非同期で行うこと。失敗した時には通知が届くようにする。
同期的な行うこともいい。変更作業→インテグレーションを繰り返しながら、待ちの間はふりかえりをすることもできる
最初のデプロイで苦労しないように、継続的インテグレーションで完全なプロダクトを作り出すようにする。
テストファーストプログラミング（Test-First Programming)
コードを変更する前に、失敗する自動テストを書くこと。テストファーストプログラミングは以下の課題を解決する
スコープクリープ
スコープを明確にでき、念の為に書くコードを削減することができる
結合度と凝集度
テストが書きにくい場合は設計を見直すこと。疎結合で低凝集になっている可能性がある
信頼
綺麗になコードかいて自動テストを書くことでメンバーから信頼される
リズム
長い時間かけて開発すると作業を見失いがちになるが、テストファーストにすることで次に何をすべきかを明確にすることができる
インクリメンタルな設計（Incremental Design）
システムの設計は一度やって終わりではなく、段階的に設計を繰り返していく。
現時点のニーズに合わせた設計をしていく。
設計をしていくタイミングは、経験した後に設計をしなおすことが効果的
何も経験をしていなくても、使用する直前に設計を繰り返すことがもっとも効率的。設計にかかる負担を減らすこともできる。
コードにおける、設計（変更）を繰り返していくと決まったパターンが見えてくる。これがリファクタリングに当たる。